Sensor based rules for responding to malicious activity

ABSTRACT

Systems and techniques are provided for creating sensor based rules for detecting and responding to malicious activity. Evidence corresponding to a malicious activity is received. The evidence corresponding to malicious activity is analyzed. Indicators are identified from the evidence. The indicators are extracted from the evidence. It is determined that an action to mitigate or detect a threat needs to be taken based on the indicators and evidence. A sensor to employ the prescribed action is identified. Whether a sensor based rule meets a threshold requirement is validated. A configuration file used to task the sensor based rule to the identified sensor is created. The number of sensor based rule triggers is tracked.

BACKGROUND

Maintaining the security of a computer system may require responding tomany different types of malicious activity. Evidence of maliciousactivity may come from multiple sources, and may come in many differentformats. The security of the computer system may be monitored byindividuals, such as, for example, cyber analysts. Cyber analysts mayreview evidence of malicious activity to determine how to strengthen thesecurity of a computer system. They may attempt to identify the targetsof the malicious activity, the actors behind the malicious activity,unique characteristics of the malicious activity, and whether anycountermeasures to mitigate the malicious activity are in place. Thecyber analyst may also decide that some action needs to be taken inresponse to the malicious activity.

BRIEF SUMMARY

Systems and techniques disclosed herein may allow for the creation andmanagement of sensor based rules for responding to malicious activity.Additional features, advantages, and embodiments of the disclosedsubject matter may be set forth or apparent from consideration of thefollowing detailed description, drawings, and claims. Moreover, it is tobe understood that both the foregoing summary and the following detaileddescription are examples and are intended to provide further explanationwithout limiting the scope of the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are included to provide a furtherunderstanding of the disclosed subject matter, are incorporated in andconstitute a part of this specification. The drawings also illustrateembodiments of the disclosed subject matter and together with thedetailed description serve to explain the principles of embodiments ofthe disclosed subject matter. No attempt is made to show structuraldetails in more detail than may be necessary for a fundamentalunderstanding of the disclosed subject matter and various ways in whichit may be practiced.

FIG. 1 shows an example system suitable for sensor based rules forresponding to malicious activity according to an implementation of thedisclosed subject matter

FIG. 2 shows an example of links between elements of creating a sensorbased rule according to an implementation of the disclosed subjectmatter.

FIG. 3 shows an example arrangement for creating and managing sensorbased rules for responding to malicious activity according to animplementation of the disclosed subject matter.

FIG. 4 shows an example of a process for creating and managing sensorbased rules for responding to malicious activity according to animplementation of the disclosed subject matter.

FIG. 5 shows a computer according to an embodiment of the disclosedsubject matter.

FIG. 6 shows a network configuration according to an embodiment of thedisclosed subject matter.

DETAILED DESCRIPTION

Sensor based rules for responding to malicious activity may be used tomaintain the security of a network infrastructure, detecting andblocking malicious activity. Evidence of malicious activity against acomputer system may be received at an analyst system running on anysuitable computing device. The evidence may be received throughautomated ingestion, or through manual entry into the system on thecomputing device, for example, by a cyber analyst. Evidence may includeany content that captures or describes activity related to computersystem that may be deemed to be suspicious. This may include filesdirectly related to the suspicious activity or reports documenting thesuspicious activity. For example, a report on an intrusion into thecomputer system involving specific software tools may be evidence.Indicators of malicious activity may be extracted from the evidence. Theindicators may include any information that may be used to uniquelyidentify a subsequent occurrence of the suspicious activity captured ordescribed by the evidence. For example, the evidence may include a rangeof IP addresses from which the intrusion into the computer systemoriginated. The range of IP addresses may be indicators of the maliciousactivity, as a subsequent network intrusion that is detected tooriginate from those IP addresses may be the same type of maliciousactivity as was captured or described in the evidence from which the IPaddress indicators were extracted. The computing device can be used tocreate a sensor based rule to detect or mitigate malicious activitybased on indicators extracted from evidence. A sensor based rule mayalso be created directly from the evidence. The evidence may be linkedto actors. The actors may be the party of parties responsible for thesuspicious activity captured or described in the evidence. For example,an actor may be a hacking group responsible for a computer systemintrusion. The actors may be automatically extracted from the evidence,and any indicators or sensor based rules created using the evidence mayalso be associated with the actors. A sensor based rule that has beencreated can then be tasked to one or more sensors, linking the sensorbased rule to the sensors to one or more sensors it is tasked to. Asensor configuration may be created in order to task the sensor basedrule to the one or more sensors. The sensor based rule may be validatedto ensure that the sensor based rule conforms to the requirements of thesensor, and then the sensor may be tasked with the sensor based rule.The number of times the sensor based rule is triggered may be tracked.The sensor based rule may be triggered when activity occurs on thecomputer system of which the computing device is a part that matches theconditions specified in the sensor based rule. For example, receivingnetwork traffic that originates from the range of IP addresses that wereextracted as an indicator from the evidence may trigger a sensor basedrule based on that range of IP addresses that has been tasked to asensor that monitors the originating IP addresses of all network trafficentering the computer system.

Evidence of malicious activity against a computer system may be enteredinto an analyst system running on a computing device. The computingdevice may be any suitable computing device that permits access to theanalyst system, such as, for example, a desktop, laptop, tablet,smartphone, or server system. The analyst system may run on any suitablecomputing device or computing devices. The evidence of maliciousactivity may be any content that captures or describes activity relatedto computer system that may be deemed to be suspicious. Evidence mayinclude any known details of the malicious activity, including the exactnature of the malicious activity, date or dates the malicious activityoccurred, actor or actors thought to be responsible, targets of themalicious activity, any known software, for example, malware, usedduring the malicious activity, including files used as droppers anddropped files, other files associated with the malicious activity, anattack pattern for the malicious activity, and a mitigation status forthe malicious activity. The evidence may include any other informationpertinent to the suspected malicious activity, such as IP addresses, MACaddresses, network traffic, domains and port numbers associated with themalicious activity, and packet capture data.

The evidence may be, for example, in the form of alerts, reports, packetcaptures, images, and query results. The alerts may be issued by anysuitable organization in any suitable format, and may include structureddata with several lines of text content that may identify the nature ofa suspected malicious activity. The reports may be issued by anysuitable organization in any suitable format, and may include structuredand semi-structured data in any suitable file format and a few pages oftext that may identify the nature of one or more incidents of suspectedmalicious activity or provide more detail on malicious activity that wasthe subject of a previous alert or report. For example, a report may bea PDF document including information about the suspected maliciousactivity. The query results may be in any suitable format, and mayinclude both semi-structured and structure data, including binary data.The query results may be the result of queries initiated by, forexample, a cyber analyst using the analyst system.

Evidence may be entered into the analyst system through automatedingestion or manual entry. For automated ingestions, the analyst systemmay include an automated ingestion engine implemented with any suitablehardware and software. The automated ingestion may include connectorswhich may be used for collecting evidence from one-to-many sources ofevidence, such as authors or publishers of cyber incident reports.Sources of reports and alerts may be polled periodically, and theautomated ingestion engine may check any new evidence that has notalready been added to the analyst system. Any new evidence may beingested into the analyst system through the connectors. An extractionengine of the analyst system may automatically analyze the evidence witha series of pattern matching rules to extract attributes of the evidenceand of the suspected malicious activity in the evidence, such asactivity dates, attack patterns, target or victim organizations, attackpatterns, and attribution of the malicious activity to an actor. Theseattributes may be stored in the analyst system, where they may be laterused as indicators or actors for the malicious activity.

Evidence may also be entered into the analyst system manually. Forexample, a cyber analyst may use a computing device to upload evidence,for example using an “Add Evidence” feature of a user interface for theanalyst system. The cyber analyst may upload a file that may include theevidence, and may add attributes and metadata about the evidence fileduring the initial upload of the file, or later. The file may be, forexample, a PDF including a report of a malicious activity that was notadded to the analyst system by the automatic ingestion engine.

Any evidence added to the analyst system, either manually, orautomatically, may be evaluated to ensure that the evidence is notalready in the analyst system. This may prevent duplicative evidencefrom being added to the analyst system. For example, the source ofevidence, and the hash of a file associated with the evidence, may becompared to evidence that has already been added to the analyst system.If there is a match, the data from the duplicate evidences may benormalized to ensure that only one entry for the evidence exists withinthe analyst system.

The analyst system may automatically extract, for example, using theautomated extraction engine, attribution, or actor, informationcontained within any new evidence added to the analyst system. The actoror attribution may automatically be added as an attribute of theevidence. The actor or attribution for evidence may automatically beinherited by any indicator or rule that is created from the evidence.This may create a linkage between actor and indicator, as the actor foran indicator may be inherited from the evidence from which the indicatorwas extracted. This may also create a linkage between an actor and arule, as the rule may inherit the actor from the indicator or evidencefrom which the rule was created.

Indicators may be extracted from the evidence in the analyst system.Once evidence is added to the analyst system, the evidence may beanalyzed automatically by an extraction engine that is part of theanalyst system. The extraction engine may analyze the evidence content,for example, a file uploaded with a report, using any suitable patternmatching rules to extract information such as, for example, IPaddresses, domain names, file MD5 hashes, email addresses, and uniquestrings, such as GET, POST, and mutexes. The extraction engine mayidentify and extract from the evidence IP, email, and domain indicatorsthat may be written in a way to not be functional as hyperlinks and MD5hashes that have leading notations to specify what format the hash isin. For example, a report including a domain name or IP address maysurround the ‘.’ character in the domain name or IP address withbrackets. The extraction engine may still extract the domain name or IPaddress as in indicator despite the inclusion of brackets in the text.Indicators may also be extracted from evidence manually, for example, bya cyber analyst. For example, a GET string in the format of a long URLmay not be automatically extracted by the extraction engine. A cyberanalyst may use the analyst system to manually extract the GET string asan indicator.

After indicators have been extracted from evidence, the indicators maybe analyzed to determine if the indicators are already in the analystsystem. For example, the analyst system may include an indicatormanagement engine, which may analyze an indicator extracted fromevidence to determine if the indicator has already been added to theanalyst system. An indicator which has not previously been added to theanalyst system may result in the creation of a new indicator object withvalues of the attributes for the indicator. The indicator may beassociated with the evidence from which the indicator was extracted,which may create a link between the evidence and the indicator. Forexample, an IP address included in a report on malicious activity may bestored as an indicator which may be linked to the report. Additionalinformation for an indicator may be determined through the performanceof a series of queries by the analyst system to auto-populate theattributes of IP address and domain indicators. For example, anindicator that includes an IP address or domain name may have additionalinformation added through the use of WHOIS query. The additionalinformation may be, for example, the identity of the registrant of adomain name, including, for example, name and address and IP addressesassociated with the domain name, or domain names and registrantsassociated with an IP address.

Each indicator extracted from an item of evidence may be presented to auser of the analyst system, for example, a cyber analyst. The cyberanalyst may evaluate the indicator to determine if the indicator may notbe useful. For example, indicators such as a domain name for awell-known website, IP addresses from a private IP space, or an MD5 hashof a null file, may be specified by the user to not be usefulindicators. This may result in teaching the extraction engine of theanalyst system to no longer extract the non-useful indicator from anyother evidence, or may only result in the non-useful indicator not beingused as an indicator for the evidence from which it was extracted. Thenon-useful indicator may also be removed from the analyst system if ithas been previously extracted from other evidence.

When the indicator is added to the analyst system through the creationof a new indicator object, or when an existing indicator object isupdated, the indicator object may inherit the actor attribution metadataor attribute from the evidence. For example, the evidence may be areport with text stating that the actor behind the malicious activitydescribed in the report is known as “The Hacking Team.” An IP addressmay be extracted from the evidence as an indicator, and used to create anew indicator object in the analyst system. The indicator object createdfor the IP address extracted from the evidence may inherit the actorattribution of “The Hacking Team” from the evidence.

An indicator may have been previously added to the analyst system, andthere may already be an indicator object in the system for theindicator. The current indicator may be combined with the indicatorobject in the analyst system, which may have data from an originalindicator that was used to originally create the indicator object. Thecurrent indicator and original indicator may be normalized into a singleindicator object. The indicator object may be linked to both theevidence from which the original indicator was extracted and theevidence from which the current indicator was extracted. The indicatorobject may inherent actor information from the current indicator. If theactor from the current indicator is different from the actor for theoriginal indicator, the indicator object may end up being attributed tomore than one actor.

Before an indicator object is added or updated in the analyst system,the indicators may be normalized. For example, brackets around ‘.’characters may be removed from email addresses, domain names and IPaddresses, the protocols and trailing directories of domain names may beremoved, file sizes may have comma removed, and MD5 hashes may have theleading notation prefix removed.

The indicators in the analyst system may be used to create sensor basedrules. A sensor based rule, or rule, may be able to detect or mitigatemalicious activity taken against the computing system and networkinfrastructure based on indicators. For example, a rule may generate analert when a sensor detects incoming traffic to the computing systemthat originates from an IP address that is an indicator, for example,that was in a report associating the IP address with malicious activity.A rule may also result in the dropping of packets, closing of ports orremoval of computing systems from access by outside networks, or anyother suitable activity that may mitigate the malicious activity. A rulecreated from an indicator, for example, by a cyber analyst using theanalyst system, may be linked to the indicator. For example, a cyberanalyst may use a user interface of the analyst system to select anindicator from which to create a rule. A rule may be created using morethan one indicator, and may inherit the actor attribute from eachindicator used to create the rule. Rules may also be created from theevidence in the analyst system. A rule created from evidence, forexample, by a cyber analyst using the analyst system, may be linked tothe evidence. For example, a cyber analyst may use a user interface ofthe analyst system to select evidence from which to create a rule.

A rule may be created for a specific type of sensor. The computingsystem may include a network infrastructure, which may have multipletypes of intrusion detection and intrusion prevention systems, such asfirewalls from different vendors, used to defend the computing systemand associated network infrastructure against malicious activity. Eachtype of intrusion detection and intrusion prevention system may have itsown sensors and associated syntax for writing rules for the sensors. Thesensors may be able to detect, in an intrusion detection system, ormitigate, in an intrusion prevention system, a unique characteristic ofa malicious activity taken against the computing device or networkinfrastructure. The syntax used for writing rules may vary, for example,based on the vendor for the intrusion detection or intrusion preventionsystem. A cyber analyst may select the sensor type a rule is beingcreated for, and the analyst system may ensure that the resultant ruleuses a syntax appropriate for the sensor, for example, based on thevendor responsible for the intrusion detection or intrusion preventionsystem of which the sensor is a part.

Rules may be created by a cyber analyst using the analyst system with adynamic text based editor. The dynamic text based editor may allow thecyber analyst to write the rule without restrictions on the ability toenter text. Syntax errors made during the creation of the rule, forexample, when the cyber analyst uses syntax that does not conform to thevendor's syntax for the sensors for which the rule is being written, maybe visually identified in the text editor so that they may be addressedby the cyber analyst.

Rules may also be created using a content based editor. The contentbased editor of the analyst system may consider the nature of the rule,the sensor type the rule is being created for and the vendorsresponsible for the sensors of that type, and any evidence andindicators associated with the rule, to identify items within theevidence and indicators that may be added to the rule. These items maybe presented to the user. For example, an indicator object in theanalyst system may include an IP address. A cyber analyst may create arule using the indicator object, and the content based editor maypresent the IP address as an item that may be used in the rule. Theanalyst system may identify the elements within the indicators orevidence that can be acted upon using rules. The analyst system may alsoidentify the elements that it may be possible for the selected rule typeto act upon. The evidence or indicator elements that can be acted onusing rules and the elements that the selected rule can act on may becross-referenced to determine active elements, which may be elements ofthe indicators or evidence based upon which the selected rule can takeaction. For example, if an rule is being created from an indicator thatincludes both an IP address and a malware file name, and the sensorassociated with the rule can take action based on IP addresses, then theIP address may be an active element for the rule while the malware filename may not be an active element for the rule.

A user interface for the content based editor may identify activeelements to the user, for example, the cyber analyst, in any suitablemanner. For example, active elements may be identified with a marker,such as an asterisk, presented alongside text describing the activeelement in the user interface. Any active elements displayed in the userinterface of the content based editor may be added to the current ruleaccording to the vendor specified syntax for the sensors associated withthe rule. A cyber analyst may be presented with a list of possibleactions that can be taken based on the active element within the rule,and may choose an action to auto-populate the rule with syntacticallycorrect code. For example, an indicator that is an IP address may beselected as a source IP address and its value may be auto-populatedwithin the rule code for the rule. The evidence may be, for example,encoded packets, and the cyber analyst may use the user interfacepresentation of the encoded packets as an active element to eithermeasure the packet length, or add the packets to the rule.

Rules may also be created by a cyber analyst with a form based editor.For example, the user interface of the analyst system may present acyber analyst with drop-down menu items and text boxes that may be usedto auto-generate a rule. The form options presented in the userinterface may be based on the syntax for the rule, for example, based onthe sensor type the rule is being generated for. The analyst system maycross references the evidence and indicator elements that can be actedupon and the rule elements that can act upon the evidence andindicators, dynamically updating the form based editor. Rules may begenerated in a syntactically correct format based on the cyber analystsinput into the form based editor.

A rule created with the analyst system may be tested against theevidence and indicators linked to the rule. Tests that may be runagainst the rule include vendor syntax compliance, best practices,packet capture network activity tests, OS audit log tests, and any othersuitable types of test. The analyst system may include a rule engine,which may determine which tests can be run for a rule based on the ruletype and the combined set of evidence and indicators linked to the rule.The results of testing rules may be presented on a user interface to acyber analyst. The cyber analyst may use the test results to determineif a rule needs to be edited, for example, if the rule is not formatcompliant or does not adhere to best practices. Traffic tests may beused to indicate what parts of network traffic were detected, which mayhelp identify noisy rules and rules that don't detect what the cyberanalyst intended. Additional evidence or indicators may be linked to anexisting rule, for example, to test if the rule will detect contentwithin the evidence or indicator.

A rule created within the analyst system may be private, and may only bevisible to the author of the rule until the author, for example, a cyberanalyst, publishes the rule to the analyst system. Publishing the rulemay make the rule visible to other users of the analyst system. A rulemay need to be published before being tasked to a sensor.

After publishing, a published rule may be tasked to one or more sensors.Based on the rule type, the analyst system may present the cyber analystwith the sensors that adhere to the vendor syntax of the rule the cyberanalyst is attempting to task. A cyber analyst may select a sensor andsubmit a request to a sensor owner for the sensor that the rule betasked to the sensor. A sensor configuration may be created for thesensor and the sensor based rule, in any suitable format. For example,the sensor configuration may be a sensor configuration file in thelanguage and syntax required by the sensor to which the sensor basedrule will be tasked. When a rule is tasked to a sensor, a detasking datemay be specified to ensure that the rule is not tasked to the sensorindefinitely. A request may also be submitted to a sensor owner todetask a rule from a sensor to which the rule has been previouslytasked.

Sensor owners, for example, a party responsible for maintaining theintrusion detection and intrusion prevention systems, may choose toaccept the request to task or detask a rule to or from a sensor. Forexample, if a new rule is created or updated and recommended for taskinga sensor, the sensor owner may evaluate the rule to determine if it issyntactically correct. The sensor owner may also run their own tests ona rule, for example, running sample network traffic against the rule outof band in a lab environment to ensure that real world traffic will notoverload systems with sensors tasked to the rule.

A rule that has been tasked to one or more sensors within the analystsystem may be linked and traceable to the sensors to which it has beentasked. The analyst system may also show which rules have been tasked toa specific sensor. The analyst system may store attributes for a rule,including the identity of the creator of the rule, whether the rule hasbeen tested, whether the rule has passed form and syntax tests, whetherthe rule has passed best practices tests, whether the rule has passedpacket capture tests, whether the rule has been published, and whetherthe rule has been tasked to any sensors. Other attributes stored by theanalyst system for a rule may include when the rule was created, whenthe rule was list triggered on a sensor to which the rule is tasked, andwhen any actors linked to the rule. A rule may also be linked to actorsbased on the linkage between actors and the evidence or indicators fromwhich the rule was created. The rule may be used to detect or blockactivities associated with the actors to which the rule is linked.

The analyst system may also track, and store as an attribute for therule, the number of times the rule has been triggered on the aggregatedset of sensors that are tasked with the rule. The analyst system maywork with a security integration and event management system todetermine the number of times a rule has been triggered. The analystsystem may keep historical track of how often, and when, a rule istriggered. The analyst system may present, on a user interface, howoften and when a rule is triggered, which may provide visibility intonormal noise levels as well as abnormal peaks and valleys in thefrequency with which the rule is triggered.

The rules in the analyst system may be searchable, and the analystsystem may maintain version histories for the rules. The versionshistories may be visible to any user, for example, cyber analyst, withproper access to the analyst system. The version history may includechanges to the rule itself, as well as changes made to the tasking ofthe rule to sensors over time. Evidence, indicators, sensors, and actorsmay also be searchable within the analyst system, and may have versionhistories as well.

For example, the analyst system may automatically import evidence, whichmay be a report of malicious activity that includes an actor, “TheHacking Team”, and several indicators including an IP address space, adomain name, and file names and MD5 hashes for dropper files and droppedfiles, for example, a dropper file that drops a Trojan horse. Theindicators may be extracted from the report, and the actor “The HackingTeam” may be linked to the indicators. A cyber analyst may review theindicators in the analyst system, and may create a rule using theindicator of the IP address space. The rule may inherit the actor “TheHacking Team” from the indicator. After creating the rule, the rule maybe tested, and then the cyber analyst may use the analyst system to taskthe rule to one or more sensors. The sensors may be, for example, partof an intrusion detection system for the computing system and networkinfrastructure the cyber analyst is seeking to protect from maliciousactivity. The sensors may monitor that originating IP addresses fortraffic entering the computing system and network infrastructure. Whenthe sensor detects traffic that originates at an IP address that is inthe IP address space in the rule, the rule may trigger. The triggeringof the rule may result in an alert being sent out, for example, to acyber analyst, or some other action to mitigate or prevent maliciousactivity being taken, such as dropping the packets whose origin IPaddresses triggered the rule. The number of times the rule is triggeredmay be monitored, which may allow, for example, a cyber analyst to gaugethe frequency of the malicious activity against the computing system andnetwork infrastructure. The cyber analyst may view the linkage betweenthe rule and the actor “The Hacking Team,” and the linkage between ruleand other indicators that were extracted from the evidence from whichthe IP address space was extracted.

Cyber analysts may use data gathered about the triggering of sensorbased rules to identify trends in the types of malicious activity thatmay be occurring against a given organization or group, which may allowfor the prioritization of mitigation activities. A cyber analyst may usethe analyst system to investigate a particular actor, in order todetermine who the actor attacks, what tools, techniques, and proceduresthe actors employ in their malicious activity, what rules exist in theanalyst system to detect activity by the actor, and which sensors aretasked to detect and mitigate malicious activity from the actor.

FIG. 1 shows an example system suitable for sensor based rules forresponding to malicious activity according to an implementation of thedisclosed subject matter. A computing device 100 may include an analystsystem 110 and a storage 140. The computing device 100 may be anysuitable computing device, such as, for example, a computer 20 asdescribed in FIG. 5, for implementing the analyst system 110 and thestorage 140. The computing device 100 may be a single computing device,or may include multiple connected computing devices, and may be, forexample, a laptop, a desktop, an individual server, a server farm, or adistributed server system. The computing device 100 may be part of acomputing system and network infrastructure, or may be otherwiseconnected to the computing system and network infrastructure. Theanalyst system 110 may be any suitable combination of hardware andsoftware on the computing device 100 and may include an ingestion engine112, extraction engine 114, rule editor 116, and rule engine 118. Thestorage 140 may store evidence 142, indicators 144, and sensor basedrules 146, sensor objects 148, and actors 150 in any suitable manner.

The ingestion engine 112 may be any suitable combination of hardware andsoftware for retrieving and ingesting evidence, which may be stored asthe evidence 142. The ingestions engine 112 may, for example,automatically retrieve alerts, reports, and query results related tosuspected incidents of malicious activity against computer systems andnetwork infrastructures. The ingestions engine 112 may, for example,poll external sources periodically for alerts and reports and to receivequery results. The ingestion engine 112 may store any retrieved evidencewith the evidence 142 in the storage 140. The evidence stored with theevidence 142 may also be retrieved manually, for example, by a cyberanalyst using the analyst system 110 on the computing device 100.

The extraction engine 114 may be any suitable combination of hardwareand software for extracting indicators from evidence. For example, theextraction engine 114 may be able to retrieve evidence stored with theevidence 142, identify and extract indicators from the evidence, andstore the extracted indicators with the indicators 144. The extractionengine 114 may use any suitable pattern matching rules to extractinformation such as, for example, IP addresses, domain names, file MD5hashes, email addresses, and unique strings, such as GET, POST, andmutexes, from evidence stored with the evidence 142. Indicatorsextracted by the extraction engine 114 may be presented to a user of theanalyst system 110 for evaluation before being as an indicator objectwith the indicators 144.

The rule editor 116 may be any suitable combination of hardware andsoftware for creating rules, for example, sensor based rules, from theevidence in the evidence 142 and the indicator objects in the indicators144. The rule editor 116 may include, for example, a form based editor,a content based editor, and a dynamic text based editor. A user of theanalyst system 110, for example, a cyber analyst, may use the ruleeditor 116 to create sensor based rules from the evidence in theevidence 142 and the indicator objects in the indicators 144. A sensorbased rule may, for example, include a specific IP address space fromwhich any packets that originate should result in an alert beinggenerated. The rule editor 116 may also be used to edit sensor basedrules already created and stored with the sensor based rules 146.

The rule engine 118 may be any suitable combination of hardware andsoftware for testing sensor based rules from the rule editor 116 beforethe sensor based rules are stored with the sensor based rules 146. Therule engine 118 may, for example, test a sensor based rule for vendorsyntax compliance and best practices, and using packet capture networkactivity tests. The sensor based rule may be edited with the rule editor116, for example, if the rule engine 118 determines that the sensorbased rule is not format compliant or does not adhere to best practices.Traffic tests may be used to indicate what parts of network traffic maybe detected by the sensor based rule, which may help identify noisyrules and rules that don't detect what the rule was intended to detect.Rules that have been tested and verified by the rule engine 118 may bestored with the sensor based rules 146.

The sensors objects 148 may represent sensors that the sensor basedrules 146 may be tasked to. For example, the sensor objects 148 mayinclude data on various sensors available on intrusion prevention anddetection systems to which a user of the computing device 100, forexample, a cyber analyst, may request one of the sensor based rules inthe sensor based rules 146 be tasked. The sensor objects 148 mayinclude, for example, data regarding valid syntax for rules for thevarious sensors, which intrusion prevention and detections systems thesensors are part of, and the identity and contact information for theparty who may handle tasking and detasking requests for the sensors.

The actors 150 may include actors extracted from the evidence storedwith the evidence 142. For example, the extraction engine 114 mayextract actors to store with the actors 150 from evidence that is to bestored with the evidence 142. The actors stored with the actors 150 mayinclude parties responsible for malicious activity described in theevidence 142. For example, the actors 150 may include the names of, andother identifying information for, individuals, groups, ororganizations.

FIG. 2 shows an example of links between elements of creating a sensorbased rule according to an implementation of the disclosed subjectmatter. There may be bi-directional linkage between evidence from theevidence 142, indicators from the indicators 144, sensor based rulesfrom the sensor based rules 146, and actors 150. The actors 150 may beindividuals, groups, organizations, or other suitable parties to whichmalicious activity can be attributed. The evidence, for example,ingested into the analyst system 110 by the ingestion engine 112, mayinclude a description of a malicious activity and an actor or actorsthought to be responsible for the malicious activity. When an indicatoris extracted from evidence, for example, an item of evidence from theevidence 142, the indicator object that is created may inherit the actorfrom the item of the evidence. This may result in a bi-directionallinkage between the item of evidence from the evidence 142, theindicator object stored with the indicators 144, and the actor from theactors 150 that was extracted from the evidence 142. The bi-directionallinkage may allow, for example, a user of the analyst system 110 todetermine all of the indicators from the indicators 144 linked to aspecific actor, all of the actors linked to a specific indicator, all ofthe indicators linked to a specific item of evidence, all of the actorslinked to a specific item of evidence, and all items of evidence linkedto a specific indicator. For example, one of the indicator objects inthe indicators 144 may be linked to multiple items of evidence, as theindicator may be common to a number of malicious activity from the sameor multiple actors. The bi-directional linkage may allow a user, such asa cyber analyst, to view all of the items of evidence and actors relatedto the indicator object, which may assist the cyber analyst inevaluating the malicious activity and any necessary actions that mayneed to be taken to mitigate the threat from the malicious activity.

Sensor based rules from the sensor based rules 146 may bebi-directionally linked to sensors 250. The sensors 250 may be anysuitable sensors for the intrusion detection and intrusion prevention.For example, the sensors 250 may include sensors that monitor the originIP addresses of packets entering a network infrastructure, sensors thatmonitor file names of files being downloaded by computing devices withinthe network infrastructure, sensors that monitor IP addresses beingaccessed by a computing device within the network infrastructure,sensors that monitor login attempts to password protected computingdevice within the network infrastructure, and so on. A sensor based rulemay be tasked to a sensor from the sensors 250, linking the sensor andthe sensor based rule. The bi-directional linkage may, for example,allow a user of the analyst system 110 to view all of the sensor basedrules from the sensor based rules 146 that have been tasked to aparticular sensor.

FIG. 3 shows an example arrangement for creating and managing sensorbased rules for responding to malicious activity according to animplementation of the disclosed subject matter. The ingestions engine112 of the analyst system 110 may access evidence from external sources300. The external sources 300 may be, for example, other computingdevices which may host reports 302, alerts 304, packet capture 308,netflow metadata 310, screenshots 312, activity logs 314, and providequery results 306 to queries that originate from the analyst system 110.The evidence from the external sources 300 may include, for example,descriptions of suspected incidents of malicious activity taken againstcomputer systems and network infrastructures, including suspected actorswho may be responsible for the malicious activity and other information,such as IP addresses, domain names and file names and MD5 hashes,associated with the malicious activity. The evidence from the externalsources 300 may be stored with the evidence 142 in the storage 140 ofthe analyst system 110. For example, the ingestion engine 112 mayretrieve a report 302 from the external sources 300 that may indicatethat a party known as “The Hacking Team” engaged in malicious activityagainst a computer system by attempting to gain unauthorized access to apassword protected computing device using a buffer overflow attackoriginating from a specific IP address.

The extraction engine 114 may analyze the items of evidence from theexternal sources 300 that was stored with the evidence 142 to identifyand extract indicators. The indicators extracted from the evidence maybe stored as indicator objects with the indicators 144. Indicators maybe any suitable information that may be used to identify a futureoccurrence of the malicious activity described in the evidence,including, for example, originating IP address, file names and MD5hashes of files, domain names, traffic patterns, packet capture data,GET and POST string, and so on. For example, the extraction engine 114may extract indicators such as the originating IP address for the bruteforce attack, packet capture data for the packets used for the bufferoverflow attack, and a POST string used in the buffer overflow attack.The indicators may be stored as indicator objects, and may be linked tothe evidence from which they were extracted. Each indicator may inheritthe actor from the evidence from which the indicator was extracted. Forexample, the originating IP address, packet capture data, and POSTstring indicators may inherit the actor “The Hacking Team” from theevidence that was ingested by the ingestion engine 112.

The rule editor 116 may be used to create a sensor based rule using anindicator object from the indicators 144. A sensor based rule mayspecify a particular indicator or indicators from an item of evidencethat a sensor should monitor for, and an action to take in the eventthat a triggering indicator is detected. For example, a user of theanalyst system 110 may use the rule editor 116 to create a sensor basedrule indicating that an alert should be generated whenever incomingnetwork traffic is detected that originates from the IP addressesextracted from the evidence of the buffer overflow attack by “TheHacking Team.” The sensor based ruled may be tested and validated by therule engine 118. The rule engine 118 may perform various tests on thesensor based rule, for example, testing the sensor based rule for propersyntax and implementation of best practices. When the rule engine 118has determined that the sensor based rule meets a threshold, the rulemay be validated. The sensor based rule may be stored with the sensorbased rules 146.

A sensor based rule from the sensor based rules 146 may be tasked to asensor in the sensors 250 of the computing system and networkinfrastructure 350. The computing system and network infrastructure 350may be any suitable number and arrangement of general computing devices,such as the computing devices 351 and 352, and network equipment, suchas, for example, hardware and software firewalls, routers, switches, andhubs. For example, the computing system and network infrastructure 350may be the computing devices and network for an organization or multipleorganizations, and may be housed within one or more structures over anygeographic region. The computing system and network infrastructure 350may also include intrusion prevention/detection system 355, which may beany suitable hardware and software, including firewalls, that may beused to monitor and protect the computing system and networkinfrastructure 350, including the computing devices 351 and 352, againstmalicious activity such as the gaining of access to the any of thecomputing device 351 and 352 by unauthorized parties.

The intrusion prevention/detection system 355 may include the sensors250, which may be any suitable sensors for monitoring activity on thecomputing system and network infrastructure 350, including incomingnetwork traffic. The sensor based ruled may be tasked to one of thesensors 250. For example, a user of the analyst system 110 on thecomputing device 100, which may be a part of or separate from andconnected to the computing system and network infrastructure 350, mayrequest that the sensor based rule for generating an alert whenevernetwork traffic originating from the IP address associated with thebuffer overflow attack is detected be tasked to one of the sensors 250that monitors the originating IP addresses of incoming network traffic.A party responsible for the sensors 250, for example, an operator of theintrusion prevention/detection system 355, may allow the request,tasking the sensor based rule to the sensor.

The sensor from the sensors 250 may monitor activity on the computingsystem and network infrastructure 350. When network activity, such asincoming traffic, includes characteristics that match an indicator thatwas used in a sensor based rule tasked to one of the sensors 250, therule may trigger. For example, when a malicious computing device 370with an IP address that matches the IP address that was an indicator ofthe buffer overflow attack sends network traffic to the computing systemand network infrastructure 350, the sensor 250 tasked with the sensorbased rule may detect the incoming network traffic. The IP address matchmay trigger the sensor based rule tasked to the sensor, resulting in thegeneration of an alert. The triggering of a sensor based rule may resultin any other suitable action, including the dropping or rerouting ofpackets, the shutting off of access to certain parts of the computingsystem and network infrastructure 350 from outside networks, or otheractions that may mitigate the threat from the malicious activityassociated with the network activity that triggered the sensor basedrule. The triggering of the sensor based rule may also be recorded, forexample, by the analyst system 110.

FIG. 4 shows an example of a process for creating and managing sensorbased rules according to an implementation of the disclosed subjectmatter. At 400, evidence corresponding to a malicious activity may bereceived. For example, the analyst system 110 may receive, through theingestion engine 112, evidence of malicious activity that was takenagainst a computer system or network infrastructure. The evidence maybe, for example, one of the reports 302 received from the externalsources 300.

At 402, the evidence may be analyzed. For example, ingestion engine 112may analyze one of the reports 302 received from the external sources300. The evidence may be analyzed for example, to determine any actorsthat may be associated with the evidence and any indicators that may beincluded in the evidence that may allow for the detection of futuremalicious activity of the type described in the evidence.

At 404, indicators and metadata may be identified in the evidence. Forexample, the extraction engine 114 may identify IP addresses, domainnames, file names, file MD5 hashes, POST and GET strings, and otherindicators that may allow for the detection of future malicious activityof the type described in the evidence.

At 406, the indicators and the metadata may be extracted from theevidence. For example, the extraction engine 114 may extract theindicators from the evidence and store them as indicator objects withthe indicators 144. The indicators extracted from the evidence may belinked to the evidence. For example, an IP address from the evidence maybe stored as an indicator object, and may be linked to the evidence.

At 408, it may be determined that an action is to be taken to mitigate athreat based on the indicators. For example, the indicators extractedfrom the evidence by the extraction engine 114 may indicate that themalicious activity described in the report from which the indicatorswere extracted may be a threat to the computing system and networkinfrastructure 350 associated with the analyst system 110.

At 410, a sensor may identified to employ to mitigate the threat. Forexample, one of the indicators of malicious activity extracted from theevidence may be an IP address. A sensor from the sensors 250 thatmonitors the originating IP addresses incoming network traffic for thecomputing system and network infrastructure 350 may be identified asbeing able to detect the indicator of the malicious activity. The sensormay be used to mitigate the threat posed by the malicious activity.

At 412, a sensor based rule may be created and validated. For example,the rule editor 116 may be used to create a sensor based rule from oneof the indicators in the indicators 144. For example, the IP addressindicator extracted from the evidence may be used to create a sensorbased rule that is triggered based on traffic from the IP address. Thesensor based rule may be validated, for example, by the rule engine 118.The validation may ensure that the sensor based rule conforms to propervendor syntax, implements best practices, and detects the intendednetwork traffic.

At 414, the sensor based rule may be tasked to the identified sensor.For example, the analyst system 110 may be used to create a sensorconfiguration for the sensor based rule, in the form of, for example, afile, with the appropriate language and syntax for the sensor. Thesensor based rule for the IP address indicator may be tasked, using thesensor configuration, to the identified sensor from the sensors 250 thatmonitors the originating IP addresses of incoming network traffic.Tasking the sensor based rule to the sensor may result in the rule beingable to trigger whenever the sensor detects network traffic thatincludes the indicator used to create the sensor based rule.

At 416, the number of times the sensor based rule triggers may betracked. For example, the sensor based ruled may trigger when the sensorfrom the sensors 250 to which the sensor based rule is tasked detects acondition that matches the indicator used to create the sensor basedrule. For example, the sensor based rule created using the IP addressassociated with the evidence of malicious activity may trigger when thesensor to which the sensor based rule is tasked detects incoming networktraffic that originates from that IP address. The number of times thesensor based rule is triggered may be tracked, and, for example, storedin the analyst system 110.

Embodiments of the presently disclosed subject matter may be implementedin and used with a variety of component and network architectures. FIG.5 is an example computer system 20 suitable for implementing embodimentsof the presently disclosed subject matter. The computer 20 includes abus 21 which interconnects major components of the computer 20, such asone or more processors 24, memory 27 such as RAM, ROM, flash RAM, or thelike, an input/output controller 28, and fixed storage 23 such as a harddrive, flash storage, SAN device, or the like. It will be understoodthat other components may or may not be included, such as a user displaysuch as a display screen via a display adapter, user input interfacessuch as controllers and associated user input devices such as akeyboard, mouse, touchscreen, or the like, and other components known inthe art to use in or in conjunction with general-purpose computingsystems.

The bus 21 allows data communication between the central processor 24and the memory 27. The RAM is generally the main memory into which theoperating system and application programs are loaded. The ROM or flashmemory can contain, among other code, the Basic Input-Output system(BIOS) which controls basic hardware operation such as the interactionwith peripheral components. Applications resident with the computer 20are generally stored on and accessed via a computer readable medium,such as the fixed storage 23 and/or the memory 27, an optical drive,external storage mechanism, or the like.

Each component shown may be integral with the computer 20 or may beseparate and accessed through other interfaces. Other interfaces, suchas a network interface 29, may provide a connection to remote systemsand devices via a telephone link, wired or wireless local- or wide-areanetwork connection, proprietary network connections, or the like. Forexample, the network interface 29 may allow the computer to communicatewith other computers via one or more local, wide-area, or othernetworks, as shown in FIG. 6.

Many other devices or components (not shown) may be connected in asimilar manner, such as document scanners, digital cameras, auxiliary,supplemental, or backup systems, or the like. Conversely, all of thecomponents shown in FIG. 5 need not be present to practice the presentdisclosure. The components can be interconnected in different ways fromthat shown. The operation of a computer such as that shown in FIG. 5 isreadily known in the art and is not discussed in detail in thisapplication. Code to implement the present disclosure can be stored incomputer-readable storage media such as one or more of the memory 27,fixed storage 23, remote storage locations, or any other storagemechanism known in the art.

FIG. 6 shows an example arrangement according to an embodiment of thedisclosed subject matter. One or more clients 10, 11, such as localcomputers, smart phones, tablet computing devices, remote services, andthe like may connect to other devices via one or more networks 7. Thenetwork may be a local network, wide-area network, the Internet, or anyother suitable communication network or networks, and may be implementedon any suitable platform including wired and/or wireless networks. Theclients 10, 11 may communicate with one or more computer systems, suchas processing units 14, databases 15, and user interface systems 13. Insome cases, clients 10, 11 may communicate with a user interface system13, which may provide access to one or more other systems such as adatabase 15, a processing unit 14, or the like. For example, the userinterface 13 may be a user-accessible web page that provides data fromone or more other computer systems. The user interface 13 may providedifferent interfaces to different clients, such as where ahuman-readable web page is provided to web browser clients 10, and acomputer-readable API or other interface is provided to remote serviceclients 11. The user interface 13, database 15, and processing units 14may be part of an integral system, or may include multiple computersystems communicating via a private network, the Internet, or any othersuitable network. Processing units 14 may be, for example, part of adistributed system such as a cloud-based computing system, searchengine, content delivery system, or the like, which may also include orcommunicate with a database 15 and/or user interface 13. In somearrangements, an analysis system 5 may provide back-end processing, suchas where stored or acquired data is pre-processed by the analysis system5 before delivery to the processing unit 14, database 15, and/or userinterface 13. For example, a machine learning system 5 may providevarious prediction models, data analysis, or the like to one or moreother systems 13, 14, 15.

In situations in which the implementations of the disclosed subjectmatter collect personal information about users, or may make use ofpersonal information, the users may be provided with an opportunity tocontrol whether programs or features collect user information (e.g., auser's performance score, a user's work product, a user's providedinput, a user's geographic location, and any other similar dataassociated with a user), or to control whether and/or how to receiveinstructional course content from the instructional course provider thatmay be more relevant to the user. In addition, certain data may betreated in one or more ways before it is stored or used, so thatpersonally identifiable information is removed. For example, a user'sidentity may be treated so that no personally identifiable informationcan be determined for the user, or a user's geographic locationassociated with an instructional course may be generalized wherelocation information is obtained (such as to a city, ZIP code, or statelevel), so that a particular location of a user cannot be determined.Thus, the user may have control over how information is collected aboutthe user and used by an instructional course provider.

The foregoing description, for purpose of explanation, has beendescribed with reference to specific embodiments. However, theillustrative discussions above are not intended to be exhaustive or tolimit embodiments of the disclosed subject matter to the precise formsdisclosed. Many modifications and variations are possible in view of theabove teachings. The embodiments were chosen and described in order toexplain the principles of embodiments of the disclosed subject matterand their practical applications, to thereby enable others skilled inthe art to utilize those embodiments as well as various embodiments withvarious modifications as may be suited to the particular usecontemplated.

1. A computer-implemented method comprising: receiving, at a computingdevice, an evidence corresponding to a malicious activity, wherein theevidence is received from an external computing device and is stored ina file by the computing device; extracting, by the computing device withan extraction engine, one or more indicators from the evidence byanalyzing the contents of the file in which the evidence was stored;creating, with the computing device, a sensor based rule from the one ormore indicators; identifying which sensor type to employ for mitigationbased on the indicator type; and creating a sensor configuration fortasking the sensor based rule to a sensor of an intrusion prevention orintrusion detection system, wherein the sensor monitors one or more ofthe computer system and a network infrastructure to which the computersystem is connected, and wherein the sensor is of the identified sensortype.